Skip to main content
Version: 2.0

Customer Needs

For two decades, I’ve seen engineering teams pay lip service to “being customer-centric.” We collect Net Promoter Scores (NPS), run user interviews, and dutifully record feature requests. But too often, this data feels… disconnected. It lands on someone else’s desk, gets summarized into a report, and rarely influences the daily decisions made by the people building the product.

The truth is, collecting feedback isn't enough. Truly understanding and acting on customer needs requires a fundamental shift in how engineering teams operate. It’s about moving beyond “voice of the customer” to a continuous, integrated feedback loop.

The Problem with Traditional Feedback Loops​

Let's be honest: the traditional model often feels like a relay race where the baton is frequently dropped. Here’s how it usually plays out:

  1. Collection: Product Managers (PMs) or UX Researchers gather feedback (surveys, interviews, support tickets, etc.). Tools like Vidhook, Survicate (which allows for easy in-app feedback collection…), or even simple email forms are used.
  2. Synthesis: The PM tries to synthesize the data, identify patterns, and prioritize them. This is where things already start to break down. It's often a subjective process, filtered through their understanding of the customer.
  3. Specification: The PM writes a user story or requirement document. A crucial layer of nuance is often lost in translation.
  4. Development: Engineers build the feature. They're working from a document – not a direct connection to the problem.
  5. Release: The feature goes out.
  6. Repeat (…eventually).

This is a reactive process. We're responding to problems that already exist, not proactively building solutions to prevent them. And critically, it removes the engineers – the people best equipped to solve the technical challenges – from the initial stages of understanding the customer.

I recall one particularly frustrating project where we built a complex reporting feature based on a lengthy requirements document. After release, it became clear the feature wasn't solving the actual problem. Customers were still struggling. We’d spent weeks building the wrong thing because the initial need hadn’t been validated directly with the engineers who would have immediately spotted the flawed assumptions. Specifically, we’d assumed customers wanted a highly detailed, configurable report. Engineers, had they been involved earlier, would have quickly pointed out that customers primarily needed a quick, high-level overview of key metrics – a much simpler solution.

Shifting to a Continuous Feedback Loop​

Here's how we can build a better system. It's not about eliminating PMs or UX – it’s about empowering the entire team.

1. Direct Exposure: Engineers need direct access to customer feedback. This isn’t about forcing them to read through thousands of support tickets (though some exposure is valuable!). It's about:

  • Rotating "Support Duty": Have engineers spend a few hours each month directly responding to customer support requests. This provides firsthand insight into pain points.
  • User Interview Participation: Invite engineers to listen in on user interviews (with customer permission, of course). The goal isn’t to interrogate the customer, but to observe and understand the why behind the requests.
  • Feedback Review Sessions: Dedicate a portion of each sprint planning meeting to reviewing recent customer feedback. Focus on the stories behind the data, not just the numbers.

2. Integrate Feedback into the Development Process:

  • Problem Statements, Not Solutions: Instead of specifying features, focus on clearly defining the problem the customer is facing. Let the engineers collaborate on potential solutions. This fosters ownership and innovation.
  • "Spike" Investigations: When a customer issue is unclear, dedicate a short "spike" – a timeboxed investigation used in Agile development – to understand the problem in more detail before committing to a solution.
  • Early Prototypes & Validation: Build rough prototypes and get them in front of customers as quickly as possible. Don’t wait for a polished product. Get feedback early and often. Tools like UserTesting.com can be helpful here.

3. Embrace Asynchronous Feedback Channels: Don't rely solely on formal processes. Encourage open communication:

  • Internal "Ask Me Anything" Sessions: Invite customers to join internal team meetings and answer questions directly.
  • Dedicated Slack Channels: Create Slack channels where engineers can easily share customer feedback and discuss solutions.
  • Regular "Customer Story" Sharing: In team meetings, have PMs or support representatives share compelling customer stories that illustrate the impact of the team's work.

A Mental Model: From Requirements to "Jobs To Be Done"​

Thinking in terms of "Jobs To Be Done" (JTBD) is a powerful way to shift the focus from feature requests to underlying customer needs. Instead of asking "What features should we build?" ask "What job is the customer trying to accomplish?"

For example, a customer might request a "complex reporting feature." But the underlying job they're trying to accomplish might be "demonstrate the value of our product to stakeholders." This opens up a wider range of potential solutions – perhaps a simpler dashboard, a pre-built presentation template, or even a dedicated customer success manager.

It’s About Culture, Not Just Process​

Ultimately, building a truly customer-centric engineering team isn’t about implementing a new process or adopting a fancy tool. It’s about fostering a culture of empathy, curiosity, and continuous learning. It's about empowering engineers to connect directly with the people they're building products for, and giving them the autonomy to solve problems in creative and impactful ways.

Implementing this shift isn't without its challenges. Existing workflows, time constraints, and potential resistance to change are real hurdles. Acknowledging these challenges upfront, and focusing on small, iterative improvements, can help build momentum and foster buy-in.

To get started, schedule a 30-minute brainstorming session with your team to identify one way to get engineers more direct access to customer feedback. By embracing a continuous feedback loop, you can empower your engineers to build products that truly solve customer problems and drive business success.